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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) 
which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Project Telecommunications and Internet Protocol 
Harmonization Over Networks (TIPHON). 



Introduction 



The approach being taken to standardization in TIPHON represents a departure from that used in the past for PSTN, 
ISDN and GSM. Its aim is to allow much greater scope for competition through innovation in the design of equipment 
and services. Its aim is also to provide adequate standardization to facilitate the operation of services across 
interconnected networks, even networks that use different technologies. The present document presents the initial core 
set of service capabilities envisaged to be required to enable service providers to offer services on TIPHON networks 
that may safely interwork with existing PSTN services while enabling more advanced services to be subsequently 
developed. 
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Figure 1 shows the relationship of the present document with other TIPHON Release 3 dehverables. 
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Figure 1 : Relationship with other TIPHON Release 3 documents 

TR 101 311 [4] provides the requirements on the transport plane, 

TS 101 878 [5] defines service capabilities that are used in the TIPHON Release 3 for a simple call, 

TS 101 882 [2] provides the Protocol Framework based on the TIPHON Release 3 architecture to implement the 
simple call service capabilities as defined in the present document, 

TS 101 315 [6] is an implementer's guide that shows how to use of the meta-protocol to realize the capabilities as 
defined in TS 101 878 [5], 

TS 101 883 [7] provides the protocol mappings for the ITU-T H-323 profile, 

TS 101 884 (see bibliography) provides the protocol mappings for the SIP profile, 

TS 101 885 (the present document) provides the protocol mappings for the ITU-T H-248 profile, 

TS 101 314 [3] provides the architecture and reference configurations for TIPHON Release 3. 
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Scope 



The present document describes how the H.248/MEGACO [1] protocol can be used to implement the architecture, 
defined in TS 101 314 [3] and the primitives, information elements and behaviours, defined in TS 101 882 [2]. 

The present document defines the mapping of the Media Control meta-protocol. 

The document is applicable to equipment performing the roles of Terminal, Gateway, Gatekeeper and also to entities 
within the IP network that are necessary to support TIPHON Release 3. 

NOTE: Where the text indicates the status of a requirement (i.e. as strict command or prohibition, as 

authorizations leaving freedom or as a capability or possibility), this may modify the nature of a 
requirement within a referenced standard used to provide the capability. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 
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[2] ETSI TS 101 882: "Telecommunications and Internet protocol Harmonization Over Networks 
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General (meta-protocol)". 

[3] ETSI TS 101 314 (V2.1.1): "Telecommunications and Internet Protocol Harmonization Over 

Networks (TIPHON) Release 3; Abstract Architecture and Reference Points Definition; Network 
Architecture and Reference Points". 

[4] ETSI TR 101 311: "Telecommunications and Internet Protocol Harmonization Over Networks 

(TIPHON) Release 3; Service Independent requirements definition; Transport Plane". 
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[6] ETSI TS 101 315: "Telecommunications and Internet Protocol Harmonization Over Networks 

(TIPHON) Release 3; Functional Entities, Information Flow and Reference Point Definitions; 
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[7] ETSI TS 101 883: "Telecommunications and Internet Protocol Harmonization Over Networks 
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H.323". 

[8] ETSI TR 101 301: "Telecommunications and Internet Protocol Harmonization Over Networks 
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[9] ETSI TR 102 008: "Telecommunications and Internet Protocol Harmonization Over Networks 

(TIPHON) Release 3; Terms and Definitions". 

[10] ETSI TS 101 520: "Telecommunications and Internet Protocol Harmonization Over Networks 
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based multimedia communications systems; Support of ITU-T Recommendation H.323". 
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[11] ETSI TS 101 521: "Telecommunications and Internet Protocol Harmonization Over Networks 

(TIPHON); Protocol Implementation Conformance Statement (PICS) proforma for the support of 
call signalling protocols and media stream packetization for packet-based multimedia 
communication systems; Support of ITU-T Recommendation H. 225.0". 

[12] ETSI TS 101 522: "Telecommunications and Internet Protocol Harmonization Over Networks 

(TIPHON); Protocol Implementation Conformance Statement (PICS) proforma for the support of 
control protocol for multimedia communication; Support of ITU-T Recommendation H.245". 

[13] ETSI TS 101 804 (all parts): "Telecommunications and Internet Protocol Harmonization Over 

Networks (TIPHON) Release 3; Technology compliance specifications". 

[14] IETF RFC 1890: "RTP Profile for Audio and Video Conferences with Minimal Control". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

call: any connection (fixed or temporary) capable of transferring information between two or more users of a 
telecommunications system 

NOTE: In this context a user may be a person or a machine. 

charging: process of determining the amount of money a user shall pay for usage of a certain service 

codec: combined speech encoder and decoder 

flow: single data stream, identified by a tuple of characteristic values (source address, source port, destination address, 
destination port, protocol number) 

functional entity: entity in a system that performs a specific set of functions 

functional group: collection of functional entities within a domain 

NOTE: In TIPHON systems Functional Groups are used to structure the necessary functionality to offer IP 
telephony services across domains. 

IP address: each network unit connected to an IP network must have a unique Internet or IP address 

NOTE: Today's IP addresses is based on IPv4 and are 32-bit numbers with its predefined structure. The IP 
address (IPv4) is written as four decimal numbers separated by a point. 

IP endpoint: device that originates or terminates the IP based part of a call 

NOTE: Endpoints include H.323 clients, and IP telephony gateways. 

IP network: packet transport network comprising one or more transport domains each employing the IP protocol 

network: telecommunications network that provides telecommunications services 

protocol: set of semantics, syntax and procedures which govern the exchange of information across an interface 

Quality of Service (QoS): quality specification of a telecommunications channel, system, virtual channel, 
computer-telecommunications session, etc. 

NOTE: Quality of Service may be measured, for example, in terms of signal-to-noise ratio, bit error rate, message 
throughput rate or call blocking probability. 
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Switched Circuit Network (SCN): telecommunications network, e.g. Public Switched Telephone Network (PSTN), 
Integrated Services Digital Network (ISDN), and General System for Mobile communications (GSM), that uses 
circuit-switched technologies for the support of voice calls 

NOTE: The SCN may be a public network or a private network. 

telephone call: two-way speech communication between two users by means of terminals connected via network 
infrastructure 

terminal: endpoint within the user equipment on which signalling and media flows originate and/or terminate 

TIPHON compliant: entity that complies with the mandatory requirements identified in the TIPHON requirements 
documents together with compliance to the parts of the TIPHON specifications in which these requirements are 
embodied 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 



BC 

CC 

IP 

MC 

QoS 

SCN 

SDL 

SIP 

ISDN 

GSM 

PSTN 



Bearer Control 

Call Control 

Internet Protocol 

Media Control 

Quality of Service 

Switched Circuit Networks 

Specification and Description Language 

Session Initiation Protocol 

Integrated Services Digital Network 

General System for Mobile communications 

Public Switched Telephone Network 



£75/ 



10 



ETSI TS 101 885 VI .1.1 (2002-03) 



Introduction 



Originating/ 
Tenninating 
Tenninal FG 



Originating/Terminating Network FG 




Home 
Npt wnric FG, 



Intermediate 
Network FG 



Terminating/ 
Originating 
Gateway FG 



QoSPE 



User 
profile 



S3 



SC2' 



S4 



S2 



M SREG ^ 



R2 



sc 



SC2 



> cc t 



BC e 



.CI 



CI 



QoSPE 



S3 



SC2' 




QoSPE 



.S4 



HhregI 



sc 



cc ^ 



BC ^ 



Nl 



N2 



i 



_CL 



C2 



SC2' 



SC2 



^ cc ^ 



^ BC ^ 



MC 



,M1 



3. 

N2 



_C2_ 



BC 



Tl 



TU 



TRM 



II 
< ► 



16 



M2 



» MC ^ 



T2 



TPE 



TU 



TRM 



Originating/ 
Terminating 
Tenninal FG 



13 



_\L. 



•* ICF 



15 



TF 



14 '\6 

12. 



M2 



t 



^ MC ^ 



T2 



TPE 



54 



TU 



M 



TRM 



~¥~ 



13 



ICF 



13 



ICF 



15 



TF 



J2 




T2 



TPE 



M 



TRM 



13 



ICF 



13 



15 



ICF 



II 



Tl 



TRM 



13 



- TF ■ ICF !► 



Ingress/Egress 
transport domain 



Core transport 
domain 



Egress/Ingress 
transport domain 



Terminating/ 
Originating 
Gateway FG 



Figure 2: TIPHON architecture with reference points N highlighted 

The present document describes an implementation of reference point N of the meta-protocol described in annex C of 
TS 101 882 [2], producing an interoperable profile of H.248/MEGACO. Figure 2 shows the TIPHON architecture 
copied from [3] with the reference points N highlighted. 

H.248/MEGACO has been created to control a range of media devices. For the purpose of the present document we 
address several categories: 

• Residential gateways implementing reference point Nl and a user interface. The user interface component is not 
addressed in this version of the present document. 

• IP-IP Media devices for the control, transcoding and monitoring of media streams in TIPHON networks. These 
devices implement reference point N2. 

• Trunk gateways, between TIPHON networks and the SCN implementing reference point N3. 
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Figure 3: Entities involved 

The mapping described in the present document describes the messages between a media gateway and its controller. 
The media gateway implements the MC functional entity as described in TS 101 314 [3] the controller implements at 
least a BC and CC entity as described in TS 101 314 [3]. 

4.1 Supported service capabilities 

This release defines media setup for basic bearers. 

QoS bearers supported in the binary encoding ONLY due to lack of support of QoS parameters in SDP. 

4.2 General note on compliance 

Any options in the H.248 protocol not mentioned in the present document MAY be supported by MG or MGC, however 
are outside the scope of TIPHON compliance and testing. 

4.3 Error handling 

The present document describes a profile that mandates certain optional parts of the H.248 protocol and does not 
mandate certain other options. General use of the error codes can be found in clause A.2. 

If an H.248 information element is received (descriptor or parameter), which is not within the context of this profile, the 
receiver shall ignore the information element and act as if the information element were not received. 

If an unknown H.248 command or an information element not within the context of this profile, the receiver shall 
ignore the command and send an appropriate error (443 - unsupported or unknown command or 444 - unsupported or 
unknown descriptor, 445 - unsupported or unknown property, 446 - unsupported or unknown parameter). 

If an H.248 command with a mandatory information element missing is received, the receiver shall act as if the 
information element was received carrying the default values, or reject with the appropriate error message if there is no 
default value specified in the ITU-T Recommendation H.248 [1]. 
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If an H.248 information element is received with syntactically invalid contents the receiver shall: 

• If the information element is optional, ignore the information element; 
or 

• If the information element is mandatory, act as if the information element was received correctly coded carrying 
the default values and reject/Fail if there is no default value specified in the present document. 

If an H.248 information element is received with a value not allowed within the context of the present document, the 
receiver shall: 

• If the information element is optional, pass on, but otherwise ignore the information element; 



• If the information element is mandatory reject/fail. 

NOTE: The security policy of an operator's network or the security policy implemented in a network element may 
override the error handling as described above. 



4.4 Security 

TIPHON does not prescribe security measures in Release 3. 



5 Setting up of IVIGC-IVIG control interface 

For TIPHON Release 3 clause 1 1 of ITU-T Recommendation H.248 [1] shall apply without restrictions. This may 
change in future releases of the present document. 



6 General notes about the TIPHON H.248 usage 

TIPHON prescribes the basic messages of H.248 and prescribes the support of certain packages depending on the 
reference point that is implemented. This clause describes the messages used, the exact encoding is given in annex B. 

The TIPHON semantics require that when multiple alternatives are returned by the MG to the MGC for a termination 
the MG shall support whichever one the MGC chooses. Failure to support parameters for a termination offered earlier is 
considered a fault. 

H.248 does not have semantics as strict as those prescribed by TIPHON. To align the semantics, ReserveGroup needs 
to be set for all alternative media flow descriptions that are requested from the MC entity and that Reserve Value needs 
to be set for all requests where the MC entity is given the choice to provide flow descriptions. 

The optional ModemDescriptor, MuxDescriptor. EventsDescriptor, DigitMapDescriptor, AuditDescriptor are not 
prescribed in this profile. 

A transaction level timer shall be provided. 

The flows in TS 101 882 [2] use an InvokingControUerReference, is mapped to StreamID in 
ITU-T Recommendation H.248 [1] 

The contextID is a value that is local to the MG-MGC relationship and is not mapped to the meta-protocol. 

The TIPHON type mcReservedMediaReference and mcEstablishedMediaReference shall be mapped to the H.248 
TerminationlD. 

Code point mapping for the Local and Remote Descriptors is provided in the annexes. 

The error codes are taken from ITU-T Recommendation H.248 [1], annex L, error codes applicable to the present 
document are described in clause A.2. 
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6.1 Packages supported 

The following packages shall be supported for all TIPHON Reference point N implementations: 

• Generic package (ITU-T Recommendation H.248 [1], clause E.l) 

• Base Root package (ITU-T Recommendation H.248 [1], clause E.2) 

• Network package (ITU-T Recommendation H.248 [1], clause E.ll) 

• RTF package (ITU-T Recommendation H.248 [ 1 ] , clause E. 1 2) 

The following packages are to be supported for each of the reference points mentioned: 
- N2 -<none> 

N3 TDM circuit package (ITU-T Recommendation H.248 [1], clause E.13) 

7 TIPHON template usage scenarios 

This clause provides template TIPHON messages for the use of H.248 on reference points N. 

The process used is given in clause 7.1. 

The generic TIPHON media flows are summarized from [2] in clause 7.2. 

In the remainder of the clause three scenarios are shown: 

7.3 Reference point N2 (IP to IP) Media Gateway without source address filtering. 

7.4 Reference point N2 (IP to IP) Media Gateway with source address filtering. 

7.5 Reference point N3 (IP to SCN) Media Gateway without source address filtering. 

7.6 Reference point N3 (SCN to IP) Media Gateway without source address filtering. 

7.1 Process used 

This clause provides the mapping of the flows in TS 101 882 [2], annex C, to H.248 message flows. Please note that the 
source is ITU-T Recommendation H.248 [1] and hence parts of H.248 may not be covered in the present document 
where they do not contribute to the requirements of TIPHON deployments. The present document also aligns the 
parameter and error reason definitions in TS 101 882 [2], annex C to ensure interoperability of these values across the 
mappings of these reference points. In general each of the primitives defined on the N reference points in 
TS 101 882 [2] each map to one or more commands in ITU-T Recommendation H.248 [1]. Please note that additional 
messaging may be necessary where applicable for the correct execution of the protocol. 

7.1 .1 General note on source filtering used in the scenarios 

SDP specifies in clause B.2.1 a means for specifying unicast sessions. This provides the means to encode the Originator 
MpoA. In clause B.2 it is shown how the recvonly and sendonly attribute are used for specifying the sender side 
behaviour of media flows. 

7.2 Default TIPHON media setup procedure 

Media control allows reservation and allocation of resources for formatting of the media stream (e.g. to reserve 
processing capability for soft codecs, or to switch into the path hard codecs). See TS 101 882 [2] for a full definition of 
the primitives involved. 

NOTE: The following text is derived from the SDL in TS 101 882 [2]. Should there be discrepancies between 
TS 101 882 [2] and the present document, the text in TS 101 882 [2] is authoritative. 
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The Media Gateway shall establish the media elements required to support the media flows required for the call. If so 
required, the media gateway shall establish a QoS controlled transport capability in accordance with the QoS class 
identified by the call control protocol. 



Step 


TS101 882 [2] Primitive 


Meaning 






BC layer decides it needs a bearer. 


1 


MediaRsvReq 


Asks the IVIC to support it with a QoS-enabled media stream (al<a a bearer) and 
wants to l<now what parameters it can support there. 


2 


IVIediaRsvConf 


The IVIC acknowledges to the BC, providing the possible bearer characteristics for 
the BC to decide upon. The MC-entity hereby commits to provide the flows as 
identified in the IVIediaRsvConf. 






The BC negotiates with peer on the bearer properties. 


3 


MediaEstReq 


The IVIC informs the IVIC of the choice. 


4 


IVIediaEstConf 


The IVIC acknowledges the establishment of the media flow. 


5 


IVIediaReleaseRequest 


The MC is requested to release the media flows. 


6 


MediaReleaseConf 


The MC confirms the release of the media flows. 



7.3 IP to IP media gateway without source filtering 

This flow assumes a reference point N2 flow with RTP terminations on two sides. 

A 



1.1.1.1:1122 


► 






1.1.1.1:1124 


■4 




2.2.2.2:2000 



3.3.3.3:4000 



2.2.2.2:2002 



3.3.3.3:4002 




B 



4.4.4.4:3300 



<L 



4.4.4.4:3302 



Figure 4: Example H.248 context 

Each termination sinks/sources one bi-directional stream with each a LocalDescriptor, RemoteDescriptor and a 
LocalControlDescriptor. The Streamlds are used to link the streams that are connected. 

For figure 4, the following table: 



Stream 


Stream Id 


Address in LocalDescr entering the 
media gateway 


Addresses in RemoteDescr leaving the 
media gateway 


Ato B 


1 


Source =* : * 

Sink =2.2.2.2:2000 


Source =* : * 

Sink =4.4.4.4:3300 


BtoA 


1 


Source =* : * 

Sink =3.3.3.3:4002 


Source =* : * 

Sink =1.1.1.1:1124 



The meta-protocol exchange above maps to the following H.248 message flow for this scenario. 
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MGC 



MG 



TransactionRequest(add) 



TransactionReply(add) 



1) MGC^MG: 

The MGC must provide the MG with enough information to a create sending and a receiving media flow. This 
information may contain codec information. The below example shows only one codec being requested, however the 
MGC may request multiple codecs. 

MEGACO/l [MGC IP Address ]: 55555 
Transaction = 1( 
Context = ${ 
Add = ${ 

Media (Stream = 1{ 
Local { 
v=0 

m=audio $ RTP/AVP [AtoMG CODEC TYPE] 
c=IN IP4 $ — for the <A-Side dest IP address of MG> 

} 

Remote { 
v=0 

m= audio 1124 RTP/AVP [MGtoA CODEC TYPE] 
C=IN IP4 1.1.1.1 

} 
} /*of Stream*/ 
} /*of Media*/ 
} /*of ADD*/ 



Add = ${ 



Media (Stream = 1{ 
Local { 
v=0 

m=audio $ RTP/AVP [BtoMG CODEC TYPE] 
c=IN IP4 $ — <B-side dest IP address of MG> 
} 

Remote { 
v=0 

m= audio $ RTP/AVP [BtoMG CODEC TYPE] 
C=IN IP4 $ — <B-side source IP address of MG> 
} 
} /*of Stream*/ 
} /*of Media*/ 
} /*of ADD*/ 
}/* of context*/ 
} /*of transaction*/ 
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2) MG^MGC: 

The MG provides the information on the possible media flows it can support. If the MG can support multiple media 

streams that satisfy the request, multiple local and remote Descriptors are to be returned. 

MEGACO/l [MG IP Address ]: 55555 
Reply = 1{ 

Context = 3001 { 
Add = 1234 { 

Media (Stream = 1{ 
Local { 
v=0 

m=audio 2000 RTP/AVP [AtoMG CODEC TYPE] 
c=IN IP4 2.2.2.2 

} 
} /*of Stream*/ 
} /*of Media*/ 
} /*of ADD*/ 
Add = 1235 1 

Media (Stream = 1{ 
Local { 
v=0 

m=audio 4002 RTP/AVP [BtoMG CODEC TYPE] 
c=IN IP4 3.3.3.3 

} 
} /*of Stream*/ 
} /*of Media*/ 
} /*of ADD*/ 
}/* of context*/ 
} /*of transaction*/ 



MGC 



MG 



TransactionRequest(modify) 



TransactionReply(modify) 



3) MGC^MG: 

If there was a choice to be made, the MGC has decided which Local/Remote Descriptor shall be used and 
collapses the choices in the terminations created. The terminations are modified by the MGC to contain only the 
Local/Remote Descriptors required. If not provided earlier, additional information such as remote transport 
addresses are filled in. 

MEGACO/l [MGC IP Address ]: 55555 
Transaction = 2{ 

Context = 3001 { 
Modify = 1235 { 

Media {Stream=l { 

Local { 
v=0 

m=audio 4002 RTP/AVP [BtoMG CODEC TYPE] 
C=IN IP4 3.3.3.3 

} 
Remote { 
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v=0 

m=audio 3300 RTP/AVP [MGtoB CODEC TYPE] 
C=IN IP4 4.4.4.4 

} 
} /*of Stream*/ 
} /*of Media*/ 
} /*of Modify*/ 
}/* of context*/ 
} /*of transaction*/ 

4) MG^MGC: 

The MG collapses the terminations to a usable state and media starts to flow. 

MEGACO/l [MG IP Address ]: 55555 
Reply = 2{ 

Context = 300H 
Modify = 1235 { } 

}/* of context*/ 
} /*of transaction*/ 

5) MGC^MG: 

When the MGC decides that the media flows are to be terminated. Terminations are subtracted in the normal 
fashion. 

TransactionRequest . 

Subtract ( originating and terminating sides } 

6) MC^BC: 



TransactionReply . Subtract 



7.4 IP to IP media gateway with source filtering 

This flow assumes a reference point N2 flow with RTP terminations on two sides. 



A 



1.1.1.1:1122 


► 




^ ^ 


1.1.1.1:1124 


•^ 




2.2.2.2:2000 



3.3.3.3:4000 



2.2.2.2:2002 



3.3.3.3:4002 




B 



4.4.4.4:3300 



4.4.4.4:3302 



Figure 5: Example H.248 context 

Each termination sinks/sources one bi-directional stream with each a LocalDescriptor, RemoteDescriptor and a 
LocalControlDescriptor. The Streamlds are used to link the streams that are connected. 

For figure 5, the following table: 



Stream 


Streamid 


Address in LocalDescr 
Entering the media gateway 


Addresses in RemoteDescr Leaving 
the media gateway 


Ato B 


1 


Source =1.1.1.1:1122 
Sink =2.2.2.2:2000 


Source =3.3.3.3:4000 
Sink =4.4.4.4:3300 


BtoA 


1 


Source =4.4.4.4:3302 
Sink =3.3.3.3:4002 


Source =2.2.2.2:2002 
Sink =1.1.1.1:1124 



The meta-protocol exchange above maps to the following H.248 message flow for this scenario. 
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MGC 



MG 



TransactionRequest(add) 



TransactionReply(add) 



1) MGC^MG: 

The MGC must provide the MG with enough information to a create sending and a receiving media flow. This 
information may contain codec information. The below example shows only one codec being requested, however the 
MGC may request multiple codecs. 

MEGACO/l [MGC IP Address ]: 55555 
Transaction = 1( 
Context = ${ 
Add = ${ 

Media (Stream = 1{ 

Local { 
v=0 

m=audio $ RTP/AVP [AtoMG CODEC TYPE] 

c=IN IP4 $ — for the <A-Side dest IP address of MG> 
a=recvonly 

m=audio 1122 RTP/AVP [AtoMG CODEC TYPE] 
C=IN IP4 1.1.1.1 
a=sendonly 

} 

Remote { 
v=0 

m= audio 1124 RTP/AVP [MGtoA CODEC TYPE] 
c=IN IP4 1.1.1.1 
a=recvonly 

m=audio $ RTP/AVP [MGtoA CODEC TYPE] 
C=IN IP4 $ 
a=sendonly 

} 
} /*of Stream*/ 
} /*of Media*/ 
} /*of ADD*/ 



Add = ${ 



Media (Stream = 1{ 
Local { 
v=0 

m=audio $ RTP/AVP [BtoMG CODEC TYPE] 
c=IN IP4 $ — <B-side dest IP address of MG> 
a=recvonly 

} 

Remote { 
v=0 

m= audio $ RTP/AVP [BtoMG CODEC TYPE] 
c=IN IP4 $ — <B-side source IP address of MG> 
a=sendonly 

} 
} /*of Stream*/ 
} /*of Media*/ 
} /*of ADD*/ 
}/* of context*/ 
} /*of transaction*/ 
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2) MG^MGC: 

The MG provides the information on the possible media flows it can support. If the MG can support multiple media 

streams that satisfy the request, multiple local and remote Descriptors are to be returned. 

MEGACO/l [MG IP Address ]: 55555 
Reply = 1{ 

Context = 3001 { 
Add = 1234 { 

Media (Stream = 1{ 

Local { 
v=0 

m=audio 2000 RTP/AVP [AtoMG CODEC TYPE] 
C=IN IP4 2.2.2.2 
a=recvonly 

m=audio 1122 RTP/AVP [AtoMG CODEC TYPE] 
C=IN IP4 1.1.1.1 
a=sendonly 

) 

Remote { 
v=0 

m= audio 1123 RTP/AVP [MGtoA CODEC TYPE] 
c=IN IP4 1.1.1.1 
a=recvonly 

m=audio 2002 RTP/AVP [MGtoA CODEC TYPE] 
C=IN IP4 2.2.2.2 
a=sendonly 

} 

} /*of Stream*/ 
} /*of Media*/ 
} /*of ADD*/ 
Add = 1235 { 

Media (Stream = 1{ 
Local { 
v=0 

m=audio 4002 RTP/AVP [BtoMG CODEC TYPE] 
C=IN IP4 3.3.3.3 
a=recvonly 

} 

Remote { 
v=0 

m= audio 4000 RTP/AVP [MGtoB CODEC TYPE] 
C=IN IP4 3.3.3.3 
a=sendonly 

} 
} /*of Stream*/ 
} /*of Media*/ 
} /*of ADD*/ 
}/* of context*/ 
} /*of transaction*/ 



MGC 



MG 



TransactionRequest(modify) 



TransactionReply(modify) 
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3) MGC^MG: 

If there was a choice to be made, the MGC has decided which Local/Remote Descriptor shall be used 
(probably after signalling with its peers) and collapses the choices in the terminations created. The terminations are 
modified by the MGC to contain only the Local/Remote Descriptors required. If not provided earlier, 
additional information such as remote transport addresses are filled in. 

MEGACO/l [MGC IP Address ]: 55555 
Transaction = 2( 

Context = 300H 
Modify = 1235 1 

Media {Stream=l { 

Local { 

v=0 

m=audio 4002 RTP/AVP [BtoMG CODEC TYPE] 

c=IN IP4 3.3.3.3 

a=recvonly 

m=audio 3302 RTP/AVP [BtoMG CODEC TYPE] 

C=IN IP4 4.4.4.4 

a=sendonly 

} 

Remote { 
v=0 

m=audio 3300 RTP/AVP [MGtoB CODEC TYPE] 
C=IN IP4 4.4.4.4 
a=recvonly 

m= audio 4000 RTP/AVP [MGtoB CODEC TYPE] 
c=IN IP4 3.3.3.3 
a=sendonly 

} 

} /*of Stream*/ 
} /*of Media*/ 
} /*of Modify*/ 
}/* of context*/ 
} /*of transaction*/ 

MG^MGC: 

The MG collapses the terminations to a usable state and media starts to flow. 

MEGACO/l [MG IP Address ]: 55555 

Reply = 2{ 

Context = 3001 { 
Modify = 1235 { } 

}/* of context*/ 
} /*of transaction*/ 

4) MGC^MG: 

When the MGC decides that the media flows are to be terminated. Terminations are subtracted in the normal 
fashion. 

TransactionRequest . 

Subtract { originating and terminating sides } 



5) MC^BC: 

TransactionReply . Subtract 
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7.5 IP-SCN Flow without source filtering 

This flow assumes a reference point N3 flow originating on an RTP termination and terminating towards SCN on the 
other. 

NOTE: H.248 allows the Circuit identification from SCN protocols to be mapped to a MG-specific 
TerminationlD. 



A 



1.1.1.1:1122 


► 




^ ^ 


1.1.1.1:1124 


< 




2.2.2.2:2000 



2.2.2.2:2002 



Circuit ID 



H248Context 




B 



TDM circuit 



\_ 



Figure 6: Example H.248 context 

Each termination sinks/sources one bi-directional stream with each a LocalDescriptor, RemoteDescriptor and a 
LocalControlDescriptor. The Streamlds are used to link the streams that are connected. 

For figure 6, the following table: 



Stream 


Streamid 


Address in LocalDescr Entering the 
media gateway 


Addresses in RemoteDescr Leaving 
tlie media gateway 


AtoB 


1 


Source =* : * 

Sink =2.2.2.2:2000 




BtoA 


1 




Source =* : * 

Sink =1.1.1.1:1124 



The meta-protocol exchange above maps to the following H.248 message flow for this scenario. 
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MGC 



MG 



TransactionRequest(add) 



TransactionReply(add) 



1) MGC^MG: 

The MGC must provide the MG with enough information to a create sending and a receiving media flow. This 
information may contain codec information. The below example shows only one codec being requested, however the 
MGC may request multiple codecs. 

MEGACO/l [MGC IP Address ]: 55555 
Transaction = 1( 
Context = ${ 
Add = ${ 

Media (Stream = 1{ 
Local { 
v=0 

m=audio $ RTP/AVP [AtoMG CODEC TYPE] 

c=IN IP4 $ — for the <A-Side dest IP address of MG> 
} 

Remote { 
v=0 

m= audio 1124 RTP/AVP [MGtoA CODEC TYPE] 
c=IN IP4 1.1.1.1 

} 
} /*of Stream*/ 
} /*of Media*/ 
} /*of ADD*/ 
Add = [TDM/$] { 

} /*of ADD*/ 

}/* of context*/ 

} /*of transaction*/ 

2) MG^MGC: 

The MG provides the information on the possible media flows it can support. If the MG can support multiple media 

streams that satisfy the request, multiple local and remote Descriptors are to be returned. 

MEGACO/l [MG IP Address ]: 55555 
Reply = 1{ 

Context = 3001 { 
Add = 1234 { 

} /*of ADD*/ 
Add = TDM/CircuitID /*of ADD*/ 

}/* of context*/ 
} /*of transaction*/ 

3) MGC^MG: 

These steps are not used, as the B-side is a TDM trunk for which all parameters are provisioned. 

4) MG^MGC 
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5) MGC^MG: 

When the MGC decides that the media flows are to be terminated. Terminations are subtracted in the normal 
fashion. 

TransactionRequest . 

Subtract ( originating and terminating sides } 

6) MC^BC: 

TransactionReply . Subtract 

7.6 SCN to IP media gateway without source filtering 

This flow assumes a reference point N3 flow originating on an SCN termination and terminating on RTP. 

NOTE: H.248 allows the Circuit identification from SCN protocols to be mapped to a MG-specific 
TerminationlD. 



A 



SCN trunk 




TDM/CircuitID 



3.3.3.3:4000 



3.3.3.3:4002 



H248Context 




B 



4.4.4.4:3300 



^ 



4.4.4.4:3302 



Figure 7: Example H.248 context 

Each termination sinks/sources one bi-directional stream with each a LocalDescriptor, RemoteDescriptor and a 
LocalControlDescriptor. The Streamlds are used to link the streams that are connected. 

For figure 7, the following table: 



Stream 


Stream Id 


Address in LocalDescr Entering the 
media gateway 


Addresses in RemoteDescr Leaving the 
media gateway 


Ato B 


1 




Source =* : * 

Sink =4.4.4.4:3300 


BtoA 


1 


Source =* : * 

Sink =3.3.3.3:4002 





The meta-protocol exchange above maps to the following H.248 message flow for this scenario. 
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MGC 



MG 



TransactionRequest(add) 



TransactionReply(add) 



1) MGC^MG: 

The MGC must provide the MG with enough information to a create sending and a receiving media flow. This 
information may contain codec information. The below example shows only one codec being requested, however the 
MGC may request multiple codecs. 

MEGACO/l [MGC IP Address ]: 55555 
Transaction = 1( 
Context = ${ 
Add = TDM/CircuitID, 
Add = ${ 

Media (Stream = 1{ 
Local { 
v=0 

m=audio $ RTP/AVP [BtoMG CODEC TYPE] 
c=IN IP4 $ — <B-side dest IP address of MG> 
} 
} /*of Stream*/ 

} /*of Media*/ 
} /*of ADD*/ 
}/* of context*/ 
} /*of transaction*/ 

2) MG^MGC: 

The MG provides the information on the possible media flows it can support. If the MG can support multiple media 

streams that satisfy the request, multiple local and remote Descriptors are to be returned. 

MEGACO/l [MG IP Address 1 : 55555 
Reply = 1{ 

Context = 3001 { 
Add = TDM/CircuitID, 
Add = 1235 { 

Media (Stream = 1{ 
Local { 
v=0 

m=audio 4002 RTP/AVP [BtoMG CODEC TYPE] 
C=IN IP4 3.3.3.3 

} 
} /*of Stream*/ 
} /*of Media*/ 
} /*of ADD*/ 
}/* of context*/ 
} /*of transaction*/ 



£75/ 



25 



ETSI TS 101 885 VI. 1.1 (2002-03) 



MGC 



MG 



TransactionRequest(modify) 



TransactionReply(modify) 



3) MGC^MG: 

If there was a choice to be made, the MGC has decided which Local/Remote Descriptor shall be used 
(probably after signalling with its peers) and collapses the choices in the terminations created. The terminations are 
modified by the MGC to contain only the Local/Remote Descriptors required. If not provided earlier, 
additional information such as remote transport addresses are filled in. 

MEGACO/l [MGC IP Address ]: 55555 

Transaction = 2( 

Context = 3001 { 
Modify = 1235 1 

Media {Stream=l{ 

Local { 
v=0 

m=audio 4002 RTP/AVP [BtoMG CODEC TYPE] 
C=IN IP4 3.3.3.3 

} 

Remote { 
v=0 

m=audio 3300 RTP/AVP [MgtoB CODEC TYPE] 
c=IN IP4 4.4.4.4 

} 
} /*of Stream*/ 
} /*of Media*/ 
} /*of Modify*/ 
}/* of context*/ 
} /*of transaction*/ 

4) MG^MGC: 

The MG collapses the terminations to a usable state and media starts to flow. 

MEGACO/l [MG IP Address ]: 55555 
Reply = 2{ 

Context = 3001 { 
Modify = 1235 { } 

}/* of context*/ 
} /*of transaction*/ 

5) MGC^MG: 

When the MGC decides that the media flows are to be terminated. Terminations are subtracted in the normal 
fashion. 

TransactionRequest . 

Subtract { originating and terminating sides } 

6) MC^BC: 



Trans act ionReply . Subtract 
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8 Options on the basic scenarios 

8.1 IVIedia activation option 

TIPHON provides the option to mute the forward media path until the call has been established. 

This has the following change to the procedure as provided above. In step 1. Set LocalControl descriptor 
{ Mode=SendOnly } to the protocol message. 

Which then looks like: 

MEGACO/l [MGC IP Address ]: 55555 
Transaction = 1( 
Context = ${ 
Add = ${ 

Media (Stream = 1{ 

LocalControl { 

Mode=ReceiveOnly, 

} 

Local { 
v=0 

m=audio $ RTP/AVP [AtoMG CODEC TYPE] 

c=IN IP4 $ — for the <A-Side dest IP address of MG> 
a=recvonly 

m=audio 1122 RTP/AVP [AtoMG CODEC TYPE] 
C=IN IP4 1.1.1.1 
a=sendonly 

} 

Remote { 
v=0 

m= audio 1124 RTP/AVP [MgtoA CODEC TYPE] 
C=IN IP4 1.1.1.1 
a=recvonly 

m=audio $ RTP/AVP [MgtoA CODEC TYPE] 
C=IN IP4 $ 
a=sendonly 

} 
} /*of Stream*/ 
} /*of Media*/ 
} /*of ADD*/ 
Add = ${ 

Media (Stream = 1{ 
Local { 
v=0 

m=audio $ RTP/AVP [BtoMG CODEC TYPE] 
c=IN IP4 $ — <B-side dest IP address of MG> 
a=recvonly 

} 

Remote { 
v=0 

m= audio $ RTP/AVP [BtoMG CODEC TYPE] 
C=IN IP4 $ — <B-side source IP address of MG> 
a=sendonly 

} 
} /*of Stream*/ 
} /*of Media*/ 
} /*of ADD*/ 
}/* of context*/ 
} /*of transaction*/ 
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Between step 4 and step 5 insert: 

The flow is set to duplex. 

MEGACO/1 [MGC IP Address ]: 55555 
Transaction = 3{ 

Context = 300H 
Modify= 1234 { 

Media {Stream = 1{ 

LocalControl { 

Mode=SendReceive, 
} 
} /*of Stream*/ 
} /*of Media*/ 
} /*of Modify*/ 
}/* of context*/ 
} /*of transaction*/ 



Generating the response: 



MEGACO/l [MG IP Address ]: 55555 
Reply = 3{ 

Context = 3001 { 
Modify = 1234 { } 

}/* of context*/ 
} /*of transaction*/ 



As is shown in TS 101 882 [2], this shall happen after the call has been accepted by the remote party. 

8.2 QoS on media flows 

The TIPHON semantics demand that an MG provides QoS when the QoS parameters are set in the Local and Control 
Descriptors. The same flows are used as in the template scenarios above. Only the H.248 binary encoding supports the 
QoS parameters to be conveyed. TIPHON intends to amend this in a separate deliverable. 

8.3 Media events 

This subject is FFS. 



IVIanagement operations 



TIPHON release 3 does not prescribe any management operations on MG. Behaviour regarding ServiceChange and 
Restart shall therefore be as specified by ITU-T Recommendation H.248 [1]. 
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Annex A (normative): 
Mapping from TS 101 882 

A.I Code point mapping 

This clause describes a generic mapping that is generally used for all primitives and parameters. 



A. 1.1 Primitive mappings 



TIPHON primitives 


H.248 message types 


MediaReservationRequest 


TransactionRequest.Add 


MediaReservationConfirm 


TransactionReply.Add 


MediaEstablishmentRequest 


TransactionRequest. Modify 


MediaEstablishmentConfirm 


TransactionReply. Modify 


MediaReleaseRequest 


TransactionRequest. Subtract 


MediaReleaseConfirm 


TransactionReply. Subtract 


TIPHON primitives with data elements 


H.248 data elements 


MediaReservationRequest 


TransactionRequest.Add 


l\/lediaHandleType (requested handle) 


Contextid (see clause 6) 


SET OF FlowDescriptorType (rx) 


LocalDescriptor 


SET OF FlowDescriptorType (tx) 


RemoteDescriptor 


MediaReservationConfirm 


TransactionReply.Add 


MediaHandleType (requested handle) 


Contextid (see clause 6) 


MediaStatusType 


See table of error messages 


SET OF MediaDescriptorWitliHandie 


LocalDescriptor, RemoteDescriptor 


MediaEstabiislimentRequest 


TransactionRequest. Modify 


MediaHandleType (reserved handle) 


Contextid (see clause 6) 


MediaEstabiislimentConfirm 


TransactionReply.Modify 


MediaHandleType (reserved handle) 


Contextid (see clause 6) 


MediaStatusType 


See table of error messages 


MediaHandleType (established handle) 


TerminationID 


MediaReleaseRequest 


TransactionRequest.Subtract 


MediaHandleType (established handle) 


TerminationID 


MediaReleaseConfirm 


TransactionReply.Subtract 


MediaHandleType (established handle) 


TerminationID 


MediaStatusType 


See table of error messages 
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A. 1.2 Binary Encoding 



A.1 .2.1 For an IP-based media flow 



TIPHON data elements 


H.248 data elements 


MediaDescriptorWithHandle 




ReservedMediaHandleType 


Contextid (see clause 6) 


FlowDescriptorType (rx) 


LocalDescriptor 


FlowDescriptorType (tx) 


RemoteDescriptor 


MediaStatusType 


See table of error messages 


RequestedMediaHandleType 


StreamID 


FlowDescriptorType 




CodecDeschptorType 




Frames per packet 


SamplePP 


Frame Rate 


Sampling rate 


SET OF TransportDescriptorType 




TransportDescriptorType 




GenericQoSDescriptorType 




SpecificQoSDescriptorType 


<not supported> 


MpoAType (originator) 


<not supported> 


MpoAType (destination) 




GenericQoSDescriptorType 




delay budget 


PropDelay 


Packet rate 


Bitrate (shall be computed as follows: 
packetRate*l\/laximumPacketSize/100) 


IVlaxim u m PacketSize 


Not used in reference point N 


Packet delay variation (jitter in milliseconds) 


Jitterbuffer 


packet loss 


<not supported> the MG shall support an 
adequately low number 


CodecDeschptorType 




Coded D (enumerated list of codecs) 


RTPpayload (IETF RFC 1890 [14]) 


SilenceSuppressionEnabled 


Silencesupp 


CodecSpecificParameters 




IPv4Type 




Address 


IPv6 


Protocol 


PortType (value =1 (UDP), RTP is implied) 


Port 


Port 


IPvBType 




Address 


IPv4 


Protocol 


PortType (value =1 (UDP), RTP is implied) 


Port 


Port 


IVIpoAType 




iPv4 


ITU-T Recommendation H.248 [1], clause C.6, 
tag value 6001 


IPv6 


ITU-T Recommendation H.248 [1], clause C.6, 
tag value 6002 


l\/lpoAProtocolType 




ENUMERATED (list from STD02) 


See above 



A. 1 .2.2 For an SCN media flow 



TIPHON data elements 


H.248 data elements 


IVIediaDescriptorWitiiHandle 




ReservedMediaHandle Type 


Contextid 


FlowDescriptorType (rx) 


TerminationID (SCN terminations are indicated 
with special TerminationlDs) 


FlowDescriptorType (tx) 


TerminationID (SCN terminations are indicated 
with special TerminationlDs) 


MediaStatusType 


See table of error messages 
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A. 1.3 Text Encoding 



A.1 .3.1 For an IP-based media flow 



TIPHON data elements 


H.248 data elements 


MediaDescriptorWithHandle 




ReservedMediaHandle Type 


Contextid (see clause 6) 


FlowDescriptorType (rx) 


LocalDescriptor (for the contents see annex D) 


FlowDescriptorType (tx) 


RemoteDescriptor (for the contents see annex D) 


MediaStatusType 


See table of error messages 


InvokingControllerMediaHandleType 


Stream ID 



A. 1 .3.2 For an SCN media flow 



TIPHON data elements 


H.248 data elements 


MediaDescriptorWithHandle 




MediaHandle Type 


Contextid (see clause 6) 


FlowDescriptorType (rx) 


TerminationID (SCN terminations are indicated 
with special TerminationlDs) 


FlowDescriptorType (tx) 


TerminationID (SCN terminations are indicated 
with special TerminationlDs) 


MediaStatusType 


See table of error messages 



A.2 Error reasons 



The following table provides a list of H.248 error reasons that an MG shall use and their corresponding TIPHON 
meanings. 



TIPHON Reason 


TIPHON diagnostic 


H.248 error reason 


flowDescriptor invalid 




444 - unsupported or unknown descriptor 


flowDescriptor not supported 


CODEC unsupported 
Framing unsupported 


515 - Unsupported stream 

445 - Unsupported or Unknown Property 


flowDescriptor unavailable 


CODEC unavailable 
QoS not available 


510 - Insufficient resources 
526 - Insufficient bandwidth 


invokingControllerReference does not 
exist 




41 1 - The transaction refers to an unknown 
Contextid 


CIrcuitID invalid 




430 - Unknown TerminationID 


CircuitID unavailable 




510 - Insufficient resources 


Insufficient resources 


no more bearers 
no more media flows 


412 - No ContextlDs available 
432 - Out of TerminationlDs or No 
TerminationID available 


mcReservedMediaReference does not 
exist 




430 - Unknown TerminationID 


mcReservedMediaReference invalid 




433 - termination ID is already in a contect 


mcReservedMediaReference unavailable 




432 - put of terminationlDs or no terminationID 
available 



Please note that TIPHON reference point N reject primitives usually pertain to a medialD within a bearerlD. H.248 
error codes are uses ad normal commands and hence apply to a particular context or termination and hence carry the 
context ID and termination ID to which the error message pertains. 
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Annex B (normative): 
Meta-protocol to SDP mapping 

SDP [1] is a description language for media sessions. This mapping therefore has no states just the codepoints. 

B.1 IVIappable fields 

The Protocol Version field (v=line) shall contain as per page 8 of ITU-T Recommendation H.248 [1]. 

The Origin field (o=line) shall be filled according to page 8 of ITU-T Recommendation H.248 [1]. 

The Session Field (s=line) shall be filled according to page 9 of ITU-T Recommendation H.248 [1]. 

The connection Field (c=line) shall contain the address value of the destinationMpoA in TS 101 882 [2]. 

• In the case of IPv4 and IPv6 addresses this shall take the form as prescribed op page 33 of ITU-T 
Recommendation H.248 [1]. 

• Other cases are undefined in ITU-T Recommendation H.248 [1] and may be extended in future versions of either 
ITU-T Recommendation H.248 [1] or the present document. 

The Bandwidth field (b=line) shall contain the value of maxP a cket Size times packetRate divided by 8 AS 
shall be used as the bandwidth modifier. 

The time filed (t=line) shall be filled according to page 14 of ITU-T Recommendation H.248 [1]. 

The Media field (m=line) shall be filled as follows: 

• <media> shall contain the type of media flow. For Release 3 this shall be audio . 

• <port> shall contain port value of the destinationMpoA in TS 101 882 [2]. 

• <transport> shall contain the text RTP/AVP . 

• <fmt list > shall be filled according to IETF RFC 1890 [14] . SDP encoding of TIPHON flow specs 
shall contain only one CODEC per m=line. 

Following attributes shall be used: 

• a=rtpmap: 

<payload type> is identical to the value in <fmt list>. 

<encoding name> is taken from IETF RFC 1890 [14]. 

<clock rate> equals the meta-protocol values packetRate * f ramesPerPacket for this media 
flow. 

<encoding parameters> is filled per page 21 of ITU-T Recommendation H.248 [1]. 

• a=ptime: shall contain the meta-protocol value of f ramesPerPacket . 

• a=fmtp: 

<f ormat> is identical to the value in <fmt list>. 

<f ormat specific parameters> shall contain the value of the meta-protocol field 

codecSpecif icParameters . 
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B.2 Specifying the OriginatorlVlpoA 

SDP specifies in clause B.2.1 a means for specifying unicast sessions. This provides the meams to encode the 
Originator MpoA. The recvonly and sendonly attribute are specifying the sender side behaviour of this message. 

The receive-only stream specifies the IP address and port where RTF should be sent to. Implicitly (port + 1) is 
the port where the RTCP should be sent to. 

The send-only stream specifies the IP address and port where RTP will be sent from. Implicitly (port H- 1) is the 
port where the RTCP will be sent from. 

EXAMPLE: m=audio 1110 RTP/AVP 
c=IN IP4 1.1.1.1 
a=recvonly 

m=audio 222 RTP/AVP 
c=IN IP4 2.2.2.2 
a=sendonly 

The sender of this SDP specifies that it wants to receive RTP packets on 1.1.1.1:1110 and send RTCP packets from 
1.1.1.1:1111. It will send RTP packets from 2.2.2.2:2220 and receive RTCP packets on 2.2.2.2:2221. 

NOTE: These semantics are compatible with current use of SDP. In the example above this leads to a scenario 
where a multihomed host receives RTP on 1.1.1.1 and sends the RTCP feedback on the stream from 
2.2.2.2. The feedback on RTP that is sent from 2.2.2.2 will be received on 1.1.1.1. A more logical 
semantics would be that the RTCP is sent from (port in recvonly + 1) and received on (port in 
sendonly + 1). This way the RTP and related RTCP stream are neatly tied together. 



B.3 Unmappable fields 

At this time SDP has no provisions for the following meta-protocol values: 

• DelayBudget; 

• packetDelayVariation; 

• packetLoss; 

• specificQoSDescriptor; 

• originatorMpoA; 

• SCN MpoAs. 

TIPHON will register codepoints in SDP with lANA for these values. 
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